A Trusted Platform Module (TPM) is a security module defined by the Trusted Computing Group (TCG) to provide protected security functions to computing platforms. Typically, it is implemented as an additional stand-alone chip attached to a PC motherboard. However, TPMs may be implemented in hardware or software.
A TPM can be considered to include various building blocks. A building block of a trusted platform TPM component is trusted to work properly without additional oversight. Trust in these components is derived from good engineering practices, manufacturing process and industry review.
Example building block components may include:—
Input/Output (I/O)
The I/O component manages information flow over a communications bus. It performs protocol encoding/decoding suitable for communication over external and internal buses. It routes messages to appropriate components. The I/O component enforces access policies associated with the Opt-In component (described below) as well as other TPM functions requiring access control.
Non-Volatile Storage
Non-volatile storage is used to store Endorsement Key (EK), Storage Root Key (SRK), owner authorisation data and persistent flags. Platform Configuration Registers (PCR) can be implemented in either volatile or non-volatile storage. They are reset at system start or whenever the platform loses power. TCG specifies a minimum number of registers to implement (16). Registers 0-7 are reserved for TPM use. Registers 8-15 are available for operating system and application use.
Attestation Identity Key (AIK)
Attestation Identity Keys must be persistent, but it is recommended that AIK keys be stored as Blobs (binary large objects) in persistent external storage (outside the TPM), rather than stored permanently inside TPM non-volatile storage. TCG hopes TPM implementers will provide ample room for many AIK Blobs to be concurrently loaded into TPM volatile memory as this will speed execution.
Program Code
Program code contains firmware for measuring platform devices. Logically, this is the Core Root of Trust for Measurement (CRTM). Ideally, the CRTM is contained in the TPM, but implementation decisions may require it be located in other firmware.
Random Number Generator (RNG)
The TPM contains a true random-bit generator used to seed random number generation. The RNG is used for key generation, nonce creation and to strengthen pass phrase entropy.
Sha-1 Engine
A Sha-1 message digest engine is used for computing signatures, creating key Blobs and for general purpose use.
RSA Key Generation
TCG standardises the RSA5 algorithm for use in TPM modules. Its recent release into the public domain combined with its long track-record makes it a good candidate for TCG. The RSA key generation engine is use to create signing keys and storage keys. TCG requires a TPM to support RSA keys up to a 2048-bit modulus, and mandates that certain keys (the SRK and AIKs, for example) must have at least a 2048-bit modulus.
RSA Engine
The RSA engine is used for signing with signing keys, encryption/decryption with storage keys, and decryption with the EK. The TCG committee anticipates TPM modules containing an RSA engine will not be subject to import/export restrictions.
Opt-In
The Opt-In component implements TCG policy requiring TPM modules are shipped in the state the customer desires. This ranges from disabled and deactivated to fully enabled; ready for an owner to take possession. The Opt-In mechanism maintains logic and (if necessary) interfaces to determine physical presence state and ensure disabling operations are applied to other TPM components as needed.
Execution Engine
The execution engine runs program code. It performs TPM initialization and measurement taking.
The TCG also has a Mobile Phone Working Group, standardising a version of the TPM—Mobile Trusted Module (MTM)—to be implemented on Mobile Equipment (ME) such as a mobile or cellular telecommunications terminal. TPM, TCG and MTM are described in the documents available at this URL: https://www.trustedcomputinggroup.org/specs/mobilephone/—which documents are fully incorporated herein by reference.
As is known, the Mobile Phone Working Group's model allows for a software application running in a Secure Execution Environment (SEE) on a mobile device to emulate the effect of a TPM chip.
MTM is an open specification for common TCG security building block functions An ME typically would contain multiple MTMs, all of which provide similar functionality to TPMs and some of which have additional functionality to boot parts of an ME into a preset state. The MTM has much in common with the current TCG specification for Trusted Platform Modules (TPM) for personal computers. However, the MTM also provides functions which have been developed specifically for mobile devices—for example to take account of limitations of mobile device technologies. MTMs with just these adoptions are called Mobile Local-owner Trusted Modules (MLTMs), since they merely support usages similar to those of existing TPMs (controlled by an entity with physical access to the platform). Additional adaptions enable parts of mobile devices (not the entire device) to boot into preset states. These MTMs are called Mobile Remote-owner Trusted Modules (MRTMs), since they enable remote entities (such as the phone manufacturers and the cellular network provider) to preset the operation of some parts of the phone (such as access to the IMEI and the cellular network).
The MTM extends security and interoperates with existing mobile device components such as SIM, USIM, and UICC cards. In addition, MTM may support security for OMA, 3GPP, MIPI, OMTP, and others. MTM are intended to allow multiple trusted devices and components to work together and share the same security infrastructures.
MTM is designed to support a “multi-stakeholder” mobile device environment. A “stakeholder” can be considered to be an entity which is authorised to have a presence in the mobile device and which needs the ability to control and protect its individual interests in the mobile device. Mobile device stakeholders include the user/owner, the network service provider, the device manufacturer and potentially others, such as enterprises and third parties. MTM has been designed to enable a trusted and shared environment that is characteristic of mobile devices. A device manufacturer and network service provider would typically use a MRTM, while the user would typically use a MLTM.
The MTM, like the TPM, protects keys and other secrets while a platform is switched off and only enables keys (and secrets) to be used by the proper entity when the MTM is securely switched on. The MTM also has commands that enable selected stakeholder applications to boot in a safe environment in the mobile device, without interfering with the rights of other stakeholders.
A separate TPM/MTM chip for a mobile device has cost implications, but also serious management implications. For instance, it is hard to move the keys on the chip between devices, and moving the entire chip is prohibited by TCG Specifications. It is also difficult to update security parameters associated with the chip (for instance adding additional cryptographic algorithms, adding additional keys, or resetting a forgotten password used to control access to a key).
TCG Specifications support a Field Upgrade command. Upgrade procedures may require field service personnel to be physically present or have owner authorisation to perform upgrade procedures. This requires interaction with the TPM “Owner” role, and so is not appropriate for background updates (invisible to the local owner), or for a case of a remote “Owner” who owns millions of TPMs. It also does not solve the migration problem—where sensitive MTM data need to be transferred from one device to another.
Turning now to another area of background to the invention, digital TV service schemes have been rolled out in a number of different countries; these schemes are often incompatible with one another. The provision of mobile digital TV services is if anything more fragmented and has in many cases not been finalised: examples of competing standards include—DVB-H, T-DMB, DAB-IP, ISDB-T, TDtv or MediaFLO.
Even within a given standard there are barriers to usage in more than one territory. The rights of content owners are to some extent protected by requiring that the content in broadcast digital TV signals is encrypted using one of a number of service protection systems. Unfortunately, regulatory authorities in different territories have not settled upon a standard service protection system.
Mobile digital TV terminals may be dedicated TV devices or mobile communications handsets (i.e. mobile or “cell”-phones) or they may be personal video recorder devices, personal digital assistants or PCs with suitable tuner components.
The provision of competing broadcast standards and use of different, incompatible rights protection systems means that, even were the same standard (say, DVB-H) adopted in different territories, for a given terminal to be Mobile TV-enabled in more than one territory will often require that the terminal has to leave the factory with firmware supporting more than one service protection solution. Indeed terminals may be arranged to support all possible service protection methods but if all these methods are not used then the licensing and development costs involved in producing a terminal that supports these methods will have been wasted. A cheaper alternative, where support for all possible service protection methods is not possible or practical, is to replace the factory provided service protection profile by a whole new service protection profile that must be downloaded over the air (OTA). This is time consuming, at best: at worst, users can be dissuaded from using services entirely.